Conversion tool for xps and openxps documents

ABSTRACT

A conversion tool enables XPS documents to be automatically converted into the Open XPS format and for Open XPS-formatted documents to be automatically converted into the XPS format. The conversion tool may convert content types, package-level relationships, part-level attributes, and image parts into a format supported by either document format.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of Ser. No. 13/178,514, filed on Jul.8, 2011, entitled “CONVERSION TOOL FOR XPS AND OPENXPS DOCUMENTS”, theentirety of which is incorporated herein by reference.

BACKGROUND

XML Paper Specification (XPS) is a paginated document format developedby Microsoft that specifies the content and appearance of an electronicdocument. Open XML Paper Specification (OpenXPS) is a paginated documentformat that is based on XPS but which differs in some respects from theformat used in XPS. OpenXPS is a standard adopted by the EuropeanComputer Manufacturers Association (ECMA) as ECMA-388. The OpenXPSstandard requires conformance to the schema defining the OpenXPS formatand the XPS specification requires conformance to the schema definingthe XPS format. Due to the differences between the two formats, it maynot be possible for XPS and OpenXPS documents to be usedinterchangeably.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

An XPS document is composed of parts and relationships. A part is a datastream similar to a file in a file system. A relationship is anassociation between one part and another part or a resource (e.g.,font). An XPS document uses a markup language (e.g., XML, XAML) todescribe a part and a relationship. The XPS Specification describes theschema that defines the syntax of the markup language. The syntaxdefines the configuration of elements, attributes and values used indescribing a part and a relationship.

An XPS document adheres to the schema described in the XML PaperSpecification version 1.0 (XPS Specification) and an OpenXPS adheres tothe schema described in the OpenXPS Standard. Although the two documentformats are similar, there are differences which prevent them from beingused interchangeably. A conversion tool is provided which recognizes thedifferences in the schema of the XPS Specification and the schema of theOpenXPS Standard and automatically converts a document formatted inaccordance with one format into a document adhering to the requirementsof the other format.

These and other features and advantages will be apparent from a readingof the following detailed description and a review of the associateddrawings. It is to be understood that both the foregoing generaldescription and the following detailed description are explanatory onlyand are not restrictive of aspects as claimed.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates an exemplary system for converting between XPS andOpenXPS documents.

FIG. 2 illustrates an exemplary diagram of a physical layout of an XPSand OpenXPS document.

FIG. 3 is a flow chart illustrating an exemplary method for convertingbetween XPS and OpenXPS documents.

FIG. 4 is a flow chart illustrating an exemplary method for convertingcontent types.

FIG. 5 is a flow chart illustrating an exemplary method for convertingpackage-level relationship types.

FIG. 6 is a flow chart illustrating an exemplary method for convertingpart-level elements and attributes.

FIG. 7 is a flow chart illustrating an exemplary method for conversionof an URI.

FIG. 8 is a flow chart illustrating conversion of color channel values.

FIG. 9 is a block diagram illustrating an exemplary operatingenvironment.

DETAILED DESCRIPTION

Overview

Various embodiments are directed to a system for converting an XPSdocument into an OpenXPS document and for converting an OpenXPS documentinto an XPS document. An XPS document adheres to the XML PaperSpecification version 1.0 (XPS Specification), currently found athttp://www.microsoft.com/xps, and which is hereby incorporated byreference. The OpenXPS standard adheres to ECMA-0388 (OpenXPS Standard),currently found athttp://www.ecma-international.org/publications/standards/Ecma-388.htm,which is hereby incorporated by reference. An XPS document should adhereto the schema set forth in the XPS Specification and an OpenXPS documentshould adhere to the schema set forth in the OpenXPS Standard. Althoughthe two document formats are similar, the differences prevent them frombeing used interchangeably. The technology described herein recognizesthe differences in the requirements of the XPS Specification and theOpenXPS Standard and automatically converts the differences found in oneformat to match the requirements needed to comply with the other format.

XPS and OpenXPS documents utilize the packaging requirements set forthin the Open Packaging Convention (OPC) standard which has been adoptedas ECMA-376(http://www.ecma-international.org/publications/standards/Ecma-388.htm)which is hereby incorporated by reference and ISO/IEC 29500:2008(http://standards.iso.org). The OPC packaging requirements specify thestructure of both an XPS and OpenXPS document. As such, the conversiontool does not modify the OPC packaging requirements.

Referring to FIG. 1, there is shown a system 100 having a conversiontool 102 that accepts an XPS document 104 and creates a correspondingOpenXPS document 106 having modifications or conversions made to adhereto the OpenXPS Standard. Likewise, the conversion tool 102 accepts anOpenXPS document 108 and creates a corresponding XPS document 110 havingconversions made to adhere to the XPS Specification. The conversion tool102 may perform conversions to the signature definition content type112, to package-level relationship types 114, to part-level elements andattributes 116, and to image formats 118. These conversions arediscussed in more detail below. Attention now turns to an overview ofXPS and OpenXPS documents.

XPS and OpenXPS Documents

An XPS and OpenXPS document are a package containing the data andresources needed to print and render an electronic document. The datamay consist of text and/or binary files that define the layout of adocument, the visual appearance of each page of a document, and thecontent included in the document. The resources may consist of filesused to distribute, render, print, and process the documents such asfonts, style definitions, bit-mapped images, color profiles, remoteresource dictionaries, etc.

An XPS and OpenXPS document are each configured into parts andrelationships. Each item in the package is considered a part. A part maybe a data stream similar to a file in a file system. Parts may be XMLfiles, XAML files, JPEG files, etc. The XPS Specification and theOpenXPS Standard each defines a schema defining the organization andstructure of the parts and when parts are needed for a particular typeof document.

Each part in a package is defined with a unique part name and a contenttype. A part name contains a uniform resource identifier (URI) that maybe used to access the part within the package. The URI can be relativeto the root of the package (i.e., absolute URI) or relative to theplacement of the part within the package (i.e., relative URI).

The content type describes the type of content in a part. The contenttype may use the Multipurpose Internet Mail Extensions (MIME) contentclassifications to describe the nature of the content in the part. Thecontent type may describe the type of data (e.g., image, audio, video,etc.) and the format of the data (e.g., xml, png, tiff, jpeg, etc.).

A relationship defines an association between one part to another partor between one part and an external resource. There are package-levelrelationships that define an association between a package and a part ora package and an external resource. There are also part-levelrelationships that define an association between a part and another partor a part and an external resource.

The XPS Specification and the OpenXPS Standard use a common logicalrepresentation of a document. A FixedDocumentSequence part describes asequence of documents. Each FixedDocumentSequence part may referenceFixedDocument parts that represent the pages of a document. Each page ofa document is referred to as a FixedPage part. Each FixedPage partcontains the text markup and layout of a page which may referenceimages, fonts, and other resources used in the page. The resourcesreferred to in a page are stored outside of the part so that they may beshared by other pages.

The XPS Specification uses a markup language (e.g., XML, XAML) todescribe a part. The markup language is based on a schema that useselements, attributes, and namespaces. The schema specifies the syntax,structure, and configuration of an XPS document. Each part may have adifferent schema. Certain elements and attributes in the XPS and OpenXPSschema are required while others are optional. The schema describing anXPS document differs from the schema describing an OpenXPS document.

FIG. 2 illustrates a block diagram of the physical structure of an XPSor OpenXPS document 200 which is also referred to as the package. An XPSor OpenXPS document has a hierarchical structure of folders and files.At the root level 202, there may be two parts or files: [ContentTypes].xml 204; and the FixedDocumentSequence.fdseq 206. At the rootlevel, there may be also three folders: _rels 208; Documents 210; andResources 212.

The [Content_Types].xml part 204 contains a list of all the contenttypes associated with each part. The content type describes the type ofcontent in a part and uses the MIME types and extensions to describe thecontent. The FixedDocumentSequence.fdseq part 206 lists all thedocuments in the package.

The folder _rels 208 stores the file _rels.rels 214 which lists all thepackage-level relationships. The folder Documents 210 is a hierarchicalstructure containing all the FixedPage parts in a document and therelationship parts associated with each FixedPage. The Documents folder210 in FIG. 2 has one document (e.g., FixedDocument.fdoc 216), which isstored in the folder /1 218, and has two pages, 1.fpage 222 and 2.fpage224, stored in the folder /pages 220. The part/Documents/1/Pages/_rels/1.fpage.rels 228 contains the relationshipsassociated with the FixedPage part 1.fpage 222 and the part/Documents/1/Pages/_rels/1.fpage.rels 230 contains the relationshipsassociated with the FixedPage part 2.fpage. The folder Resources 212contains a font part, font1.odtff 232, an image part, image1.png 234,and an ICC color profile, colorprofile1.icc, 236 that may be used toprint the two pages of the document.

Although the package 200 shown in FIG. 2 has a limited number of folderand files in a certain configuration, it should be appreciated that thepackage 200 can include more or less folders and files in alternateconfigurations.

Attention now turns to a discussion of the various embodiments of theoperations used in the system with reference to various exemplarymethods. It may be appreciated that the representative methods do notnecessarily have to be executed in the order presented, or in anyparticular order, unless otherwise indicated. Moreover, variousactivities described with respect to the methods can be executed inserial or parallel fashion, or any combination of serial and paralleloperations. The methods can be implemented using one or more hardwareelements and/or software elements of the described embodiments oralternative embodiments as desired for a given set of design andperformance constraints. For example, the methods may be implemented aslogic (e.g., computer program instructions) for execution by a logicdevice (e.g., a general-purpose or specific-purpose computer).

XPS and OpenXPS Conversion

Referring to FIG. 3, there is shown an exemplary method 300 forconverting an XPS document into an OpenXPS document and for convertingan OpenXPS document into an XPS document. The method starts byconverting a signature definition content-type element in one formatinto the other format (block 302), converting package-level relationshiptypes in one format into the other format (block 304), convertingpart-level elements and attributes of certain parts from one format intothe other format (block 306), converting certain image parts from oneimage format into another image format (block 308), and generating a newpackage in the new format (block 310).

Conversion of SignatureDefinition Content Type

FIG. 4 illustrates a flow chart of an exemplary method for convertingthe Signature Definition part's content type to the converted format.

XPS supports the capability of digitally signing an XPS document as ameans to provide proof of authenticity to an XPS document. ASignatureDefinition part is used to indicate specific information usedin the digital signature process such as the signing parties,co-signature requirements, and so forth.

An exemplary XML markup for a SignatureDefinitions part is shown inTable 1. The xml namespace is defined by the SignatureDefinitions xmlnselement (e.g., SignatureDefinitionsxmlns=“http://schemas.microsoft.com/xps/2011/01/signature-definitions”).The signer of the XPS document is identified in the Signer Nameattribute and the SpotID attribute is a globally unique identifier forthe signature spot (e.g., SignatureDefinition SignerName=“Jane Doe”SpotID=“1234”). The Spot Location element indicates the page on whichthe signature spot may be displayed (e.g.,PageURI=“/Documents/2/Pages/3.fpage”) and the placement of the signaturespot on the page (e.g., StartX=“0.0”, StartY=“0.0”)

The Intent element specifies the intention of the signatory whendigitally signing the document (e.g., <Intent> I have read theconditions, understand them, and agree to them <Intent>), the SignByelement specifies the data and time by which the signatory is to signthe document (e.g., <SignBy>Aug. 3, 2011</SignBy>), and theSigningLocation element specifies the legal location where the documentis to be signed (<SigningLocation> New York, N.Y. </Signing Location>).

TABLE 1 <SignatureDefinitionsxmlns=”http://schemas.microsoft.com/xps/2011/01/signature- definitions”><SignatureDefinition SignerName=”Jane Doe” SpotID=”1234”> <Spot LocationPageURI=”/Documents/2/Pages/3.fpage” StartX=”0.0” StartY=”0.0” /><Intent> I have read the conditions, understand them, and agree to them<Intent> <SignBy>August 3, 2011</SignBy> <SigningLocation>New York, NY</Signing Location> <SignatureDefinition> </SignatureDefinitions>

XPS uses a default content type for the Signature Definition part. InOpenXPS, a Signature Definition part requires a specific content typewhich differs from the default content type used in XPS. In convertingan XPS document to an OpenXPS document, the OpenXPS content type isinserted into the Signature Definition part. When converting an OpenXPSdocument to an XPS document, the content type for the SignatureDefinition part is deleted and replaced with the default content type.

Referring to FIG. 4, in the case of converting from an XPS document toan OpenXPS document (block 402), the conversion tool 102 searches forparts having an .xaml (Extensible Application Markup Language) fileextension (block 404). Xaml is an XML-based language having additionalelements that provide the capabilities to create and animate userinterface objects. Parts having an .xaml file extension that aredigitally signed use a default ContentType, such as <Default ContentType=“application/xml” Extension=“xaml”/>. This default content typedoes not adequately identify the contents of a Signature Definitionspart as being a Signature Definitions part. By contrast, OpenXPSrequires that a Signature Definitions part have a Content Type elementthat definitively indicates that the part is a Signature Definitionspart.

In order to determine if a part having a xaml file extension is aSignature Definition part, the conversion tool 102 reads each .xaml part(block 406) and scans for Signature Definition indicators, such as theelements and attributes that are within the SignatureDefinition partschema described in Table 1 (block 408). Some of these elements andattributes are optional while others are required so the schema employedin an xaml part may differ from that shown in Table 1. When theconversion tool 102 finds at least one of the elements and/or attributesassociated with a SignatureDefinition part schema (block 408), theconversion tool may replace the default Content Type with the requiredOpenXPS Content Type, which may have the form, <ContentType=“application/vnd.ms-package.xps-signaturedefinitions+xml”/> (block410).

In the case of converting from an OpenXPS document to an XPS document(block 412), the conversion tool 102 searches the package for partshaving an .xaml file extension (block 414). Each such part is read(block 416) for an OpenXPS Content Type element having a value thatmatches the string,“application/vnd.ms-package.xps-signaturedefinitions+xml” (block 418).The OpenXPS Content Type element is deleted and replaced with thedefault Content Type which may be constructed in the form <DefaultContent Type=“application/xml” Extension=“xaml”/> (block 418).

Conversion of Package-Level Relationship Types

FIG. 5 illustrates a flow chart of an exemplary method for convertingXPS-formatted package-level relationship types to a correspondingOpenXPS-formatted package-level relationship type and for convertingOpenXPS-formatted package-level relationship types to a correspondingXPS-formatted package-level relationship type.

A relationship defines an association between one part to another partor between one part and an external resource. There are package-levelrelationships that identify relationships between the package and partswithin the package and relationships between the package and externalresources. A relationship element is used to configure a relationshipbetween a package and a part. The relationship element may be formattedin XPS as shown in Table 2 below.

TABLE 2 <Relationships xmlns =”http://schemas.openxmlformats.org/package/2006/relationships”><Relationship Type =”http://schemas.microsoft.com/xps/2005/06/restricted-font” Target =“/Resources/1298DD23234D443D2.ODTTF” Id=”A1”/ > </Relationships>

The exemplary relationship shown in Table 2 associates the package witha restricted font part. A restricted font is one that cannot be modifiedor have any edits made to certain elements of the font. The relationshipassociates a package referred to by the namespace,http://schemas.xmlformats.org/package/2006/relationships, with a partreferred to as A1, which is identified by the Id attribute (e.g.,Id=“A1”). The Type attribute identifies the namespace of the restrictedfont (e.g., http://schemas.microsoft.com/xps/2005/06/restricted-font)and the Target attribute identifies the local location of the fontwithin the package.

Referring to FIG. 5, in the case of converting an XPS document to anOpenXPS document (block 502), the conversion tool 102, reads thepackage-level relationships which are stored in the part named_rels/.rels (block 504). At the root level, there is a folder _rels thatstores the part named _rels/.rels that contains the package-levelrelationships. The conversion tool 102 reads the _rels/.rels part (block504) and scans the values of the Type attribute associated with aRelationship element. In particular, the conversion tool 102 searchesfor the values for an XPS Relationship Type element and replaces themwith the corresponding value for the same OpenXPS Relationship Typeelement shown in Table 3 (block 506). For example, if the conversiontool 102 finds the following markup

<RelationshipType=“http://schemas.microsoft.com/xps/2005/06/restricted-font”the conversion tool 102 may convert the value of the Relationship Typeelement to the following:<RelationshipType=“http://schemas.openxps.org/oxps/v1.0/restricted-font”.This replacement may be performed for all the XPS Relationship Typeelements shown in Table 3.

TABLE 3 Part XPS Relationship Type OpenXPS Relationship Type Digitalhttp://schemas.microsoft.com/xps/2005/06/signature-definitionshttp://schemas.openxps.org/oxps/v1.0/signature-definitions SignatureDefinitions Discardhttp://schemas.microsoft.com/xps/2005/06/discard-controlhttp://schemas.openxps.org/oxps/v1.0/discard-control Control Documenthttp://schemas.microsoft.com/xps/2005/06/documentstructurehttp://schemas.openxps.org/oxps/v1.0/documentstructure Structure PrintTicket http://schemas.microsoft.com/xps/2005/06/printtickethttp://schemas.openxps.org/oxps/v1.0/printticket Requiredhttp://schemas.microsoft.com/xps/2005/06/required-resourcehttp://schemas.openxps.org/oxps/v1.0/required-resource ResourceRestricted http://schemas.microsoft.com/xps/2005/06/restricted-fonthttp://schemas.openxps.org/oxps/v1.0/restricted-font Font Storyhttp://schemas.microsoft.com/xps/2005/06/storyfragmentshttp://schemas.openxps.org/oxps/v1.0/storyfragments Fragments

In the case of converting an OpenXPS document to an XPS document (block508), the conversion tool 102 reads the package-level relationshipsfound in the part named _rels/.rels (block 510). The conversion tool 102reads the values of the Relationship Type elements. In particular, theconversion tool 102 searches for each of the values of OpenXPSRelationship Type elements shown in Table 3 and replaces them with thecorresponding values of the same XPS Relationship Type element shown inTable 3 (block 512). For example, if the conversion tool 102 finds thefollowing markup

<RelationshipType=“http://schemas.openxps.org/oxps/v1.0/restricted-font”

the conversion tool 102 may convert the value of the Relationship Typeelement to the following markup

<RelationshipType=“http://schemas.microsoft.com/xps/2005/06/restricted-font”. Thisreplacement may be performed for all the OpenXPS Relationship Typeelements shown in Table 3.

At the package-level, these conversions may be applied to the followingparts: Digital Signature Definitions; DiscardControl; DocumentStructure;PrintTicket; Required Resource; Restricted Font; and StoryFragments.

Conversion of Part-Level Elements and Attributes

FIG. 6 illustrates a flow chart of an exemplary method for convertingcertain XPS-formatted part-level elements and attributes to anOpenXPS-formatted equivalent and for converting certainOpenXPS-formatted part-level elements and attributes to an XPS-formattedequivalent. More particularly, the method converts XPS-formattednamespaces to a corresponding OpenXPS-formatted namespace, XPS-formattedrelationship types to a corresponding OpenXPS-formatted relationshiptype, XPS-formatted URIs to a corresponding OpenXPS-formatted URI, andXPS-formatted color channel values to a corresponding OpenXPS-formattedcolor channel value. Attention now turns to a description of each ofthese conversions.

A namespace is a collection of names which are used as elements andattributes in an XML document. An XML namespace is identified by a URIreference. The namespaces used in certain parts in an XPS document maydiffer from the namespaces used in the same part of an OpenXPS document.As such, the namespaces for each of the parts that differ need to beconverted to the proper namespace. The parts having namespaces thatdiffer in both the XPS and OpenXPS formats are found in Table 4. Foreach part listed in Table 4, the conversion tool 102 replaces each ofthe XPS-formatted namespaces with the corresponding OpenXPS-formattednamespace shown in Table 4.

TABLE 4 Part XPS Namespace OpenXPS Namespace Discard <Discard Controlxmlns = <Discard Control xmlns = Controlhttp://schemas.microsoft.com/xps/2005/06/http://schemas.openxps.org/oxps/v1.0/ discard-control /> discard-control/> Document <Document Structure xmlns = <Document Strucuture xmlns =Structure http://schemas.microsoft.com/xps/2005/06/http://schemas.openxps.org/oxps/v1.0/ documentstructure />documentstructure /> Fixed <FixedDocument xmlns = <FixedDocument xmlns =Document http://schemas.microsoft.com/xps/2005/06/ />http://schemas.openxps.org/oxps/v1.0/ /> FixedDocument<FixedDocumentSequence xmlns = <FixedDocumentSequence xmlns = Sequencehttp://schemas.microsoft.com/xps/2005/06/ />http://schemas.openxps.org/oxps/v1.0/ /> Fixed Page <FixedPage xmlns =<FixedPage xmlns = http://schemas.microsoft.com/xps/2005/06/ />http://schemas.openxps.org/oxps/v1.0/ /> Resource <Resource Dictionayxmlns = <Resource Dictionary xmlns = Dictionaryhttp://schemas.microsoft.com/xps/2005/06/http://schemas.openxps.org/oxps/v1.0/ resourcedictionary-key />resourcedictionary-key /> Signature <Signature Defintions xmlns =<Signature Definitions xmlns = Definitionshttp://schemas.microsoft.com/xps/2005/06/http://schemas.openxps.org/oxps/v1.0/ signature-definitions />signature-definitions /> Story <Story Fragments xmlns = <Story Fragmentsxmlns = Fragments http://schemas.microsoft.com/xps/2005/06/http://schemas.openxps.org/oxps/v1.0/ documentstructure />documentstructure />

Each part has a corresponding relationship part that identifies theassociations between the part and other parts or external resources. Therelationship part has a filename that is constructed with elements fromthe part's part name and has a file extension of .rels. For certainparts, the URI indicated in the Relationship Type element is differentin the XPS Specification from the URI specified in the OpenXPS Standard.For these certain parts, the conversion tool 102 converts theXPS-formatted URI of a Relationship Type element to a correspondingOpenXPS-formatted URI and converts an OpenXPS-formatted URI of aRelationship Type element to a corresponding XPS-formatted URI. Theparts requiring this conversion are the Digital Signature Definitionspart, the Discard Control part, the Document Structure part, thePrintTicket part, the Required Resource part, the Restricted Font part,the StartPart part, and the StoryFragments part. The parts requiringthese conversions are listed in Table 3 along with the XPS-formattedvalues and the OpenXPS-formatted values.

A uniform resource identifier (URI) is used to access a part. Anabsolute URI is an absolute address or absolute file path to thelocation of a part. A relative URI is configured in accordance with RPC3986, Uniform Resource Identifier (URI) Generic Syntax(http://tools.ietf.org/html/rfc3986). A relative URI can have anabsolute file path that starts with the forward slash character (“/”) orhas a file path that is relative to the root of the package using thepackage root as the base URI. XPS supports both absolute and relativeURIs. OpenXPS requires relative URIs to be used for FixedDocument, FixedPage, Font, and Image parts. As such, when converting from an XPSdocument to an OpenXPS document, the conversion tool 102 converts eachabsolute URI into a relative URI for the <Document Reference> element ina FixedDocument part, for the <Page Content> element in a Fixed Pagepart, for the <Glyphs> element in a Font part, and an <ImageBrush>element of an Image part.

Various elements may use a Color attribute to identify a particularcolor in a well-defined color space. The Color attribute may be used inan element to print or render a particular image, object, or textstring. Examples of such elements are the <Solid Color Brush> elementand the <Gradient Stop> element. The <Solid Color Brush> element may beused to paint an area with a solid color and the <Gradient Stop> elementmay be used to paint an area with a gradient color. The syntax of theColor attribute may be configured as follows:

<Color=“ContextColor Profile URI channel values”>,where the text string “ContextColor” indicates that a particular coloris being specified, the text string “Profile URI” is the URI of thecolor profile being used, and the text string “channel values” identifythe intensity levels for each channel in the color profile. Colorprofiles are parts having a file extension of .icc and may be stored inthe Resources folder of the package.

A color channel or channel refers to a component of a color space. Thereare several well-known color spaces, such as RGB (Red, Green, Blue),CMYK (Cyan, Magenta, Yellow, Black), HLS (Hue, Luninance, Saturation),HSV (Hue, Saturation, Value), and Grayscale. Each color space isassociated with a certain number of components, each component beingreferred to as a channel. For example, RGB is associated with 3components or channels: red; green; and blue. As such, RGB is referredto as a 3-channel color space. Each channel has a value indicating anintensity level for that channel. For example, the channel valuesassociated with the 3-channel RGB color space may be represented as 1,2, 5, where the channel value for red is 1, the channel value for greenis 2, and the channel value for blue is 5.

In the XPS Specification, the syntax of the Color attribute specifies aminimum of 3 channel values. In the case of a color space that uses lessthan 3 channels, such as Grayscale, zeros are added in the channel valuetext string to conform to this requirement. For example, in XPS thefollowing Color attribute

<Color=“ContextColor Grayscale.icc 0.5, 0, 0”>

indicates that a grayscale coloring is used which is a one channel colorspace and where the intensity level is 0.5 for the channel. Theadditional zeros represent fillers not associated with any channel.

In the OpenXPS Specification, the syntax of the Color attribute requiresthat there are no zero fillers used as color channel values. Instead,each color channel value is associated with an actual channel. In orderto comply with the syntax requirements of both formats, the conversiontool 102 scans the channel values specified in each Color attribute.When converting from an XPS document to an OpenXPS document, if zerosare used as a channel value, the conversion tool determines whether thezero is an actual channel value or a filler. The conversion tool 102converts the channel values to the appropriate format if the zero valuesare fillers. When converting from an OpenXPS document to an XPSdocument, if there are less than 3 channel values in the Colorattribute, additional zeros are appended to the end of the channel valuestring accordingly.

Attention now turns to a description of the operation of each of theseconversions. Referring back to FIG. 6, when converting from an OpenXPSdocument to an XPS document (block 614) and when converting from an XPSdocument to an OpenXPS document (block 602), the conversion tool 102locates and opens each part in the package (block 604, block 614). Theconversion tool 102 reads each line in each part and looks for theXPS-formatted namespace elements listed in Table 4 and replaces themwith the corresponding OpenXPS-formatted namespace element listed inTable 4 (block 606). Similarly for the conversion from an OpenXPSdocument to an XPS document, for each part, the conversion tool checksfor the OpenXPS-formatted namespace values and replaces them withcorresponding XPS namespace values (block 618). This conversion isperformed for at least the Discard Control, Document Structure, FixedDocument, Fixed Document Sequence, Fixed Page, Resource Dictionary,Signature Definitions, and Story Fragments parts.

Next, for each part listed in Table 3, the conversion tool 102 locatesthe corresponding relationship part (e.g., [partname].rels file) andreplaces the Relationship Type elements with the Relationship Typeelement found in Table 3 (block 608, block 620).

Next, the conversion tool 102 converts an absolute URI for certainelements in certain parts to an equivalent relative URI in accordancewith the OpenXPS Standard (block 610). Referring to FIG. 7, theconversion is only performed when converting from an XPS document to anOpenXPS document (block 702-yes). Otherwise (block 702-no), there is noneed for the conversion since the XPS Specification supports bothrelative and absolute URI addresses. For each part listed in Table 5,the conversion tool 102 searches for the element referred to in Table 5and checks the URI associated with that element (block 704).

For those URI values that are not in relative form, the conversion tool102 converts the URI to relative form and replaces that value in thecorresponding element (704). In converting from an absolute URI value toa relative URI value, the conversion tool 102 calculates the shortestpath from the parent part in the package to the child part in thepackage. For example, if the URI value of the parent part is“/Documents/1/Pages/FixedPage.fpage” and the URI value of the child partis “/Documents/Resources/Images/image.bmp”, then relative URI value is“../../Resources/Images/image.bmp.” The conversion tool 102 parses theparent's URI value until a common folder is found or the package root isfound. The character “../” replaces the part of the child's URI valuethat is common and the rest of the child's URI value is added to therelative URI value.

TABLE 5 Part Elements having URIs to Check FixedDocument<DocumentReference> Fixed Page <Page Content> Font URI <Glyphs> ImageURI <Image Brush>

Referring back to FIG. 6, the conversion tool 102 checks the colorattributes using ICC color profiles (e.g.,Color=“ContextColor/Colors/channelprofile.icc 1.0, 0.8, 0, 0”) andconverts the color channel values if necessary (block 612, block 622).Referring to FIG. 8, when converting from an XPS document to an OpenXPSdocument (block 802), the conversion tool 102 matches the number ofcolor channel values specified in the color attribute with the number ofchannel values needed for the specified color profile (e.g., .icc file)(block 804). The file header information in the specified color profilefile contains the number of channel values needed for the specifiedcolor profile. If the number of color channel values specified in thecolor attribute differs from the number of channel values needed for thespecified color profile, then the conversion tool 102 eliminates thezero fillers that do not correspond to a channel thereby converting thecolor attribute to the OpenXPS format (block 806).

When converting from an OpenXPS document to an XPS document (block 808),if there are less than three channel values specified in a colorattribute, (e.g., Color=“ContextColor/Colors/channelprofile.icc 1.0,0.8, 1.5”), the conversion tool 102 adds additional zero fillers to theend of the channel value text string so that there are at least 3channel color values (block 810).

Referring back to FIG. 3, the conversion tool 102 converts the format ofimage parts that are not supported by either format. XPS recognizes andsupports the JPEG format (Joint Photographics Experts Group), the PNGformat (Portable Network Graphics), TIFF format (Tagged Image FileFormat) and HD Photo image formats. By contrast, OpenXPS recognizes andsupports the JPEG, PNG, TIFF, and JPEGXR (Joint Photographics ExpertsGroup XR) image formats. The HD Photo image format is not supported bythe OpenXPS Standard and the JPEGXR image format is not supported by theXPS Specification. When converting an XPS document to an OpenXPSdocument, the conversion tool converts each HD Photo image to a JPEGXRimage format through an image conversion tool (block 308). In the caseof converting an OpenXPS document to an XPS document, the conversiontool converts each JPEGXR image to a HD Photo image through an imageconversion tool (block 308). In at least one embodiment, the WindowsImage Converter may be used to facilitate these conversions although anyavailable image converter that has the capability of converting an HDPhoto image to an JPEGXR image and vice versa may also be used.

Create New Package

Referring back to FIG. 3, after all of the above-mentioned conversionshave been made, a new package is created in the desired format. Each ofthe above-mentioned conversions generated a new part, instead ofaltering the existing part, and after all the conversions have beenperformed a new package is generated thereby completing the conversion(block 310). The new package may be generated using OPC applicationprogramming interfaces (APIs).

It should be noted that the methods illustrated herein may berepresentative of some or all of the operations executed by one or moreembodiments described herein and that each method can include more orless operations than that which is described above. In addition, thesequence of the steps may be performed in alternate configurations foran intended implementation.

Operating Environment

Referring now to FIG. 9, there is shown a schematic block diagram of anexemplary operating environment 900. The operating environment 900 mayinclude one or more client(s) 902 in communication through acommunications framework 904 with one or more server(s) 906. In anembodiment, a client 902 may be configured to contain one or more XPSdocuments 916 that may need to be converted into an OpenXPS document 918and/or one or more OpenXPS documents 918 that may require conversion toan XPS document 916. A server 906 may receive requests from one or moreclients 902 along with a package and may facilitate the conversion forthe client 902. The server 906 may then provide the converted package,XPS document 916 or OpenXPS document 918, back to the client 902. Inanother embodiment, the conversion tool 102 may reside in the client 902thereby enabling the client 902 to perform the intended conversionwithout the need for the server's involvement. In yet anotherembodiment, a server 906 may be configured to contain one or more XPSdocuments 930, one or more OpenXPS documents 932, and a conversion tool928. The server 906 may perform an intended conversion without receivingrequests from any clients 902.

A client 902 may be embodied as a hardware device, a software module, oras a combination thereof. Examples of such hardware devices may include,but are not limited to, a computer (e.g., server, personal computer,laptop, etc.), a cell phone, a personal digital assistant, or any typeof computing device, and the like. A client 902 may also be embodied asa software module having instructions that execute in a single executionpath, multiple concurrent execution paths (e.g., thread, process, etc.),or in any other manner.

A server 906 may be embodied as a hardware device, a software module, oras a combination thereof. Examples of such hardware devices may include,but are not limited to, a computer (e.g., server, personal computer,laptop, etc.), a cell phone, a personal digital assistant, or any typeof computing device, and the like. A server 906 may also be embodied asa software module having instructions that execute in a single executionpath, multiple concurrent execution paths (e.g., thread, process, etc.),or in any other manner.

The communications framework 904 facilitates communications between theclient 902 and the server 906. The communications framework 904 mayembody any type of communications medium, such as wired or wirelessnetworks, utilizing any communication protocol.

A client 902 may have a processor 908 and a memory 910. The memory 910may be any computer-readable storage media or computer-readable mediathat may store processor-executable instructions, procedures,applications, and data. The computer-readable media does not pertain topropagated signals, such as a modulated data signal transmitted througha carrier wave. It may be any type of memory device (e.g., random accessmemory, read-only memory, etc.), magnetic storage, volatile storage,non-volatile storage, optical storage, DVD, CD, floppy drive, diskdrive, flash memory, and the like. The memory 910 may also include oneor more external storage devices or remotely located storage devices.The memory 910 may contain instructions and data as follows:

an operating system 912;

a conversion tool 914;

one or more XPS documents 916;

one or more OpenXPS documents 918; and

various other applications and data 920.

A server 906 may have a processor 922 and a memory 924. The memory 924may be any computer-readable storage media or computer-readable mediathat may store processor-executable instructions, procedures,applications, and data. It may be any type of memory device (e.g.,random access memory, read-only memory, etc.), magnetic storage,volatile storage, non-volatile storage, optical storage, DVD, CD, floppydrive, disk drive, flash memory, and the like. The memory 924 may alsoinclude one or more external storage devices or remotely located storagedevices. The memory 924 may contain processor-executable instructionsand data as follows:

an operating system 926;

a conversion tool 928;

one or more XPS documents 930;

one or more OpenXPS documents 932; and

various other applications and data 934.

CONCLUSION

The foregoing description has described embodiments of a conversion toolthat automatically converts an XPS document into an OpenXPS document andan OpenXPS document into an XPS document. The conversion tool providesan automatic and comprehensive technique to perform the conversion thatis less prone to errors and more time efficient than a manual process.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

Various embodiments may be implemented using hardware elements, softwareelements, or a combination of both. Examples of hardware elements mayinclude devices, components, processors, microprocessors, circuits,circuit elements, integrated circuits, application specific integratedcircuits, programmable logic devices, digital signal processors, fieldprogrammable gate arrays, memory units, logic gates and so forth.Examples of software elements may include software components, programs,applications, computer programs, application programs, system programs,machine programs, operating system software, middleware, firmware,software modules, routines, subroutines, functions, methods, procedures,software interfaces, application program interfaces, instruction sets,computing code, code segments, and any combination thereof. Determiningwhether an embodiment is implemented using hardware elements and/orsoftware elements may vary in accordance with any number of factors,such as desired computational rate, power levels, bandwidth, computingtime, load balance, memory resources, data bus speeds and other designor performance constraints, as desired for a given implementation.

Some embodiments may comprise a storage medium to store instructions orlogic. Examples of a storage medium may include one or more types ofcomputer-readable storage media capable of storing electronic data,including volatile memory or non-volatile memory, removable ornon-removable memory, erasable or non-erasable memory, writeable orre-writeable memory, and so forth. Examples of the logic may includevarious software components, such as programs, procedures, module,applications, code segments, program stacks, middleware, firmware,methods, routines, and so on. In an embodiment, for example, an articleof manufacture may store executable computer program instructions that,when executed by a processor, cause the processor to perform methodsand/or operations in accordance with the described embodiments. Theexecutable computer program instructions may be implemented according toa predefined computer language, manner or syntax, for instructing acomputer to perform a certain function. The instructions may beimplemented using any suitable high-level, low-level, object-oriented,visual, compiled and/or interpreted programming language.

In various embodiments, the system 100 described herein may comprise acomputer-implemented system having multiple components, programs,procedures, modules. As used herein these terms are intended to refer toa computer-related entity, comprising either hardware, a combination ofhardware and software, or software. For example, a component may beimplemented as a process running on a processor, a hard disk drive,multiple storage drives (of optical and/or magnetic storage medium), anobject, an executable, a thread of execution, a program, and/or acomputer. By way of illustration, both an application running on aserver and the server may be a component. One or more components mayreside within a process and/or thread of execution, and a component maybe localized on one computer and/or distributed between two or morecomputers as desired for a given implementation. The embodiments are notlimited in this manner.

The embodiments described herein refer to XPS documents and OpenXPSdocuments that adhere to a particular specification and standard.However, the embodiments are not limited to these specifications andstandard and may be used in compatible specifications and standards,such as future versions of the specifications and standards of thoserecited herein. An XPS-compatible document is one that adheressubstantially to the schema of the XPS version 1.0 Specificationincluding, but not limited to, all versions and revisions of thisspecification, even though they may not be referred to using the term“XPS.” Similarly, an OpenXPS-compatible document is one that adheressubstantially to the schema of the OpenXPS version 1.0 Standardincluding, but not limited to, all versions and revisions of thisstandard, even though they may not be referred to using the term“OpenXPS.”

What is claimed:
 1. A method implemented on a computing device having at least one processor, the method comprising: receiving a first document configured as a first package formatted in accordance with a first syntax, the first document including at least one file; identifying at least one signature definition element in the at least one file, the at least one signature definition element associated with a digital signature for the first document; converting a signature definition element formatted in the first syntax to a signature definition element formatted in the second syntax, the first syntax differs from the second syntax; generating a second document configured as a second package formatted in the second syntax, the second package including the signature definition element formatted in the second syntax; and storing the second package.
 2. The method of claim 1, wherein the first package and the second package contain data and resources needed to print an electronic document.
 3. The method of claim 1, wherein the first package and the second package contain data and resources needed to render an electronic document.
 4. The method of claim 1, wherein converting the signature definition element formatted in the first syntax to a signature definition element formatted in the second syntax, further comprises: searching for a Signature Definition part in the first package; and inserting a content type into the Signature Definition part of the second package.
 5. The method of claim 1, wherein converting the signature definition element formatted in the first syntax to a signature definition element formatted in the second syntax, further comprises: searching for a Signature Definition part in the first package; deleting a content type associated with the Signature Definition part of the first package; and adding in a default context type to the Signature Definition part of the second package.
 6. A device, comprising: at least one processor and a memory; the at least one processor configured to: receive a first package formatted in a first syntax, the first package including at least one file, the at least one file including a package-level relationship element or a part-level element adhering to the first syntax, the package-level relationship element identifying a relationship between the first package and the at least one file, the part-level element identifying a relationship between the at least one file and a second file included in the first package; convert the package-level relationship element or the part-level relationship element in the first syntax to a corresponding package-level relationship element or part-level relationship element in a second syntax, the second syntax differs from the first syntax; and generate a second package formatted in the second syntax that includes the package-level relationship element or the part-level relationship element in the second syntax.
 7. The device of claim 6, wherein the first package is used to render and/or print a document.
 8. The device of claim 6, wherein the package-level relationship element associates the first package with a restricted font file.
 9. The device of claim 6, wherein the package-level relationship element associates a namespace associated with the package with the at least one file.
 10. The device of claim 6, wherein the package-level relationship element identifies a relationship between the first package and an external resource.
 11. The device of claim 6, wherein convert the package-level relationship element in the first syntax to a corresponding package-level relationship element in the second syntax further comprises: changing a value associated with the package-level relationship element in the first syntax to a different value associated with the second syntax.
 12. The device of claim 6, wherein convert the part-level relationship element in the first syntax to a corresponding part-level relationship element in a second syntax, further comprises: changing a value associated with the part-level relationship element in the first syntax to a different value associated with the second syntax.
 13. The device of claim 6, wherein the part-level relationship element represents a namespace, a color channel value or a universal resource identifier (URI).
 14. The device of claim 6, wherein the first package and the second package utilize a common packaging requirement.
 15. The device of claim 6, wherein the first package and the second package utilize a packaging requirement set forth in the Open Packaging Convention standard.
 16. A system, comprising: at least one processor and a memory; the at least one processor configured to: receive a first document configured as a first package with data and resources to print and/or render the first document, the first document including one or more files and at least one relationship between the files, the first document adheres to a first syntax; convert at least one element in at least one of the one or more files in the first syntax to a corresponding element in a second syntax; generate a second document configured as a second package in a second syntax, the second document including the corresponding element in the second syntax, the first syntax differs from the second syntax; and store the second document.
 17. The system of claim 16, wherein the at least one element represents a signature definition element associated with a digital signature associated with the first document.
 18. The system of claim 16, wherein the at least one element represents a package-level relationship between the first document and the at least one file.
 19. The system of claim 16, wherein the at least one element represents a part-level relationship between a first element included in a first file of the first document and a second element included in a second file of a second document of the first document.
 20. The system of claim 16, wherein the at least one element represents a package-level relationship between the first document and an external resource. 